マイクロサービスアーキテクチャ 第2版
https://m.media-amazon.com/images/I/51Me4hVZfWL._SY291_BO1,204,203,200_QL40_ML2_.jpg
初版と比較してページが倍増、内容モリモリで改定されたマイクロサービスアーキテクチャ第2版、読んでいきます。
/icons/hr.icon
Notes
はじめに
2014年の初版から、世の中もテクノロジーもだいぶ進化した。筆者の勘所もさらに研ぎ澄まされた
Kubernetes、モダンなデプロイパイプラインなども盛り込んでいる
1章 マイクロサービスとは
一般的なマイクロサービスの解説。慣れ親しんだ人はSkipしてもいいかも。復習のために読むのは良き
独立性の担保は重要。特にデータベースの共有に関しては要注意。
マイクロサービスのサイズはそれほど気にしなくても良い。増えすぎても問題になる。→ 漸進的に進めていきましょう (急激にではなく、順を追ってだんだんと進めていくべし)
システムの変更はビジネスの変更によって生じる。従来の3層アプリケーション (プレゼンテーション層、ビジネスロジック層、データ層) を考える場合に、基本的にはすべてのレイヤで変更が生じる。3層アプリケーションをベースとしたチーム分け (→ いわゆるコンウェイの法則) ではコストが重くなる。→ 垂直方向にビジネス軸でチームをわけるのも良い選択肢。
モノリスは複雑である。モジュラーモノリス、分散モノリスなど。分散モノリス → 何らかの理由でサービスは分離されているが、サービス間の依存が強く、すべてを同時にリリースする必要があるサービス群、という類のもの
モノリス = 悪 ではない。レガシーというわけでもない。思考停止でマイクロサービスといっちゃうのが一番問題。
マイクロサービス導入時に、多くのツールや新技術を入れないようにすること。まずは慣れたものや知っているものを中心に使ったほうがよい。あとから変えればいいのだから。
とは言え重要なこともある → ログ集約と分散トレーシング
OSSのトレーシング → Jaeger、製品: ：LightStep, Honeycombなどは発展的なもの。
コンテナ化やKubernetesの利用は急ぐ必要はない。労力が必要になるケースが多い (特にKubernetes)
ストリーミング技術が重要な役割を果たすことが多い。サーバーレスを利用してクラウドベンダーに頼るのもよし。
サービスごとに採用する技術を分けて良い。一方で技術が増えるとオーバーヘッドも多くなるのは注意。
あるサービスが落ちても稼働を続けられるために堅牢性は高いが、従来とは違うモニタリングの手法が必要。デプロイが容易。
マイクロサービスのデメリットを理解しておくべし → 複雑性が増すことによる困難が多く待っているぞ
テストの困難さ、コスト、遅延、モニタリングの複雑性、セキュリティ、分散されたデータ （困難な集計、レポート）
ドメインモデリングできていないのにマイクロサービスをやるのはむずい。サービス境界を設計できない。
スケーラビリティを欲するあまり、運用できないマイクロサービス群が出来上がっては意味がない。
マイクロサービスを納品する、みたいなケースはとても辛いのでやめたほうがいい
自分たちでオーナーシップを持って開発し、進化させ続ける自信があるのであればマイクロサービスは適している
2章マイクロサービスのモデル化
架空の会社 MusicCorp での事例
オンライン小売
実店舗からオンラインへの変遷
設計上の重要な3つの要素
情報隠蔽
凝集
結合
情報隠蔽
モジュールの利点そのもの。みんなカプセル化するでしょう？
理解しやすいInterfaceは重要。依存性を排除せよ
凝集
依存している機能は同じサービスへ。デプロイ時に影響が無い機能は別のサービスに分離可能。
一度に複数のサービスをデプロイしないように、これが重要
凝集度が高く、結合度が低い場合に構造は安定する
すべての結合を排除することなどできない。結合とうまく付き合うべし
ドメイン結合 (複雑性マシマシ)、パススルー結合 (後続のサービスにデータを渡して処理を委ねること。後続の処理に対して知識を持つ必要があるため、問題になるケース多い)
サービス内のデータモデル変更が他サービスに影響するようなケースを割ける。つまりロックステップロールアウト : 依存のあるサービスを同時にロールアウトする、をしない設計を。(具体例が説明されている)
データの依存が排除できない場合にステートマシンサービスを作る手もある
DBへのCRUDだけを行うようなマイクロサービスは、凝集がうまくできていない例かもしれない。CRUDだけを切り出しても意味はない。(データの書き換えをオープンにすることになるので複雑度が増す)
内容結合: 上流サービスが下流サービスの内部に影響して、内部状態を変更すること。はぁ？？ 外部サービスから勝手にデータ書き換える。どういうケースよ‥ → 例えば下流サービスの機能を迂回してデータを書き換えちゃうようなケースか。特権サービスみたいなものを作って何でもかんでもやるのはアンチパターンかも？そういうわけではないか。
なにはともあれ内容結合は絶対に避けてくれ、とのこと。外から自分のデータベースを触らせるな！ってこと。
DDDの話。ちょっとDDDを知っている前提の解説なのでDDD知らないとツラいかもしれない
状態機械ってなんやねん？って思ったらステートマシンね。
RDBを使って外部キーで結合するようなデータモデルをサービスを超えて扱う場合、その関係をモデル化する何らかの方法が必要
説明で出てくる例を噛み砕いて理解するのが難しい
DDDの境界づけられたコンテキストが、明示的に情報隠蔽の粒度になっている。もってもってDDDの考え方はマイクロサービスの考え方と相性が良い。マイクロサービスの境界を見つけるのに不可欠。
一方でDDDが唯一解というわけではない。
3章 モノリスの分割
マイクロサービスは目標ではない。現在のアーキテクチャで目標が達成できないときに考えよう。
漸進的に移行すべし。ビッグバン書き換えをしたときに待っているのはビッグバンであるｗｗｗ
ワイの場合、かつてのとあるモノリス解体の体験が、モノリス → マイクロサービス の考え方に悪影響をしているのでアンラーニングしたほうが良さそう。ドラスティックにモノリスをマイクロサービス化できることは基本的には無いと考えよ。そして大半がそれをやる必要が無い。（ビジネス場はもっと重要なことがあるはず。）
マイクロサービス分割すべきもの → 頻繁に変更されている機能、一方で切り出しの容易性は常に意識すべき。切り出すのが難しいような機能はモノリスのままにしておいたほうが良いかもしれない。要はバランス。
切り出しは コードファーストか、データファーストか？ 個人的にはデータファーストかなぁ。ただし分散トランザクションや冪等性の担保で課題になるケースが多そう。
サーガなど (6章) で分散トランザクションを解決するパターンもあるものの、データの切り出しは複雑性が増加することを覚悟すべし
モノリスからマイクロサービスへの分割についてもっと知りたければ別書を読んでね。とのこと。
4章 マイクロサービスの通信スタイル
マイクロサービス間通信のオーバーヘッドはモノリスのそれと比較すると、オーバーヘッドが極大であることを理解せよ
通信のパターン
同期ブロッキング
構成がシンプルで、モノリスと同じ考え方が通用する
処理が遅くなる。トランザクション処理においてリソース競合を引き起こす可能性がある。
デッドロックや輻輳の原因にも。
非同期非ブロッキング
実行時間の長いタスクなどに有利。
複雑になる。馴染み深い構成にならないので慣れが必要。
リクエスト/レスポンス
同期、非同期、どちらでも構成が可能。
タイムアウト、デッドロック回避などの仕組みは必須。
イベント駆動
共通データ
通信やInterfaceに依らないサービス連携が可能。超レガシーなメインフレームで動くようなアプリケーションであっても、ファイルの読み書きぐらいはできるであろう。
(個人的には積極的に使いたいものではない)
7章 ビルド
あなたの CI、本当にCIをやっていますか？ ビルドが壊れたとき、その修正がチームの最優先事項であるべき。
オープンソースとプロダクトのCIは別物なので注意スべし。プロダクト開発の際は可能な限り素早く (DORA的には1日以内に) 変更が本線にマージされるべきだが、OSS開発では有象無象のContributionを正しく精査スべき。
Continues Delivery (各チェックインを成果物として扱う概念) と Continues Deploy (各チェックインを検証して自動的にデプロイする) は別物よ
7.2.1 多くのケースに置いて、CIツールをハックしてCDを行っている。CIとCDは別物であり、CDに関しても専用のツールやサービスを利用するのが望ましい
成果物の生成は一度だけにせよ。その成果物をチェックし、テストし、リリースするのだ
マルチリポ: 管理が容易だが、サービス間の依存がある場合の更新が難しい。リポジトリ間のコードの再利用に課題。横断的な変更は標準ではなく例外として扱う。そもそも複数のRepositoryにまたがる更新が頻発する場合、サービス境界の設計が悪いとも言える
モノリポ: 管理が複雑になりがち。Bazelなどを採用するのも良い。コードの再利用性に優れている。権限管理が難しい。
モノリポをやりたい場合、現実的にはチームごとにモノリポを作るのがよい。組織全体でやるには、それを作って運用するための潤沢なリソースが必要になる。モノリポは運用に相応の覚悟が必要、あとから分離も難しいケースが多いので、マルチリポから始めるのが良いかもしれない。
8章 デプロイ
アプリケーションのインスタンス管理はクラウドサービス等のプラットフォーム機能に頼るのが原則
ここでも出てきた、「データベースは共有しない」の原則。データベースはサービス内で確実に隠蔽すべき。一方で論理的にはデータベースがわかれていても、物理的には同じホストに載せることもある(主にオンプレの場合)。この場合はホスト障害によって複数のマイクロサービスへの致命的なダメージを考慮すべき。可能であれば物理的にデータベースをわけよう。クラウドを活用すれば容易。
10章 監視から可観測性へ
分散トレーシング
分散トレーシングのツールやサービスの基本的な挙動はすべて同じ。分散環境に配置されるローカルエージェントと、中央コレクタによる情報の集約。
Local Activityが「スパン」内に補足される。収集するデータは使用するプロトコルによって異なる。OpenTracing APIの場合は開始時刻、終了時刻、関連するログ、任意のKVデータなどが含まれる。
基本的にはサンプリングされる。GoogleのDapperではランダムサンプリング。一方でHoneycombやLightstepのようなモダンなツールでは動的サンプリング、つまりエラーはすべてサンプリングして成功ケースは100回に1回だけサンプリングする、などの設定が可能。
OpenTracing APIでスパンを補足するが、このスパン情報を中央のコレクタに送る方法が必要になる。
OSS分野ではJaegerが、商用サービスではHoneybombやLightstepが推奨。その他を選定する際も、基本的にはOpenTelemetry APIに対応したものを選ぶこと！
非常に多くの情報を収集できるが、何をもって「システムが正常に動作しているか」を考え、監視が形骸化しないようにするのが最も重要である。
/icons/hr.icon
目次
第Ⅰ部 基礎
1章 マイクロサービスとは
1.1 マイクロサービスの概要
1.2 マイクロサービスの重要な概念
1.2.1 独立デプロイ可能性
1.2.2 ビジネスドメインに基づくモデル化
1.2.3 マイクロサービスごとの状態の所有
1.2.4 サイズ
1.2.5 柔軟性
1.2.6 アーキテクチャと組織の連携
1.3 モノリス
1.3.1 単一プロセスモノリス
1.3.2 モジュラーモノリス
1.3.3 分散モノリス
1.3.4 モノリスとデリバリ競合
1.3.5 モノリスの利点
1.4 実現技術
1.4.1 ログ集約と分散トレーシング
1.4.2 コンテナとKubernetes
1.4.3 ストリーミング
1.4.4 パブリッククラウドとサーバレス
1.5 マイクロサービスの利点
1.5.1 技術の異種性
1.5.2 堅牢性
1.5.3 スケーリング
1.5.4 デプロイの容易性
1.5.5 組織との連携
1.5.6 合成可能性
1.6 マイクロサービスの課題
1.6.1 開発者体験
1.6.2 技術の過負荷
1.6.3 コスト
1.6.4 レポート
1.6.5 監視とトラブルシューティング
1.6.6 セキュリティ
1.6.7 テスト
1.6.8 遅延
1.6.9 データ一貫性
1.7 マイクロサービスを使うべきか
1.7.1 役立たない場合
1.7.2 効果的な場所
1.8 まとめ
2章 マイクロサービスのモデル化
2.1 MusicCorpの紹介
2.2 適切なマイクロサービス境界にするには
2.2.1 情報隠蔽
2.2.2 凝集
2.2.3 結合
2.2.4 結合と凝集の相互関係
2.3 結合の種類
2.3.1 ドメイン結合
2.3.2 パススルー結合
2.3.3 共通結合
2.3.4 内容結合
2.4 過不足のないドメイン駆動設計（DDD）
2.4.1 ユビキタス言語
2.4.2 アグリゲート（集約）
2.4.3 境界づけられたコンテキスト（コンテキスト境界）
2.4.4 アグリゲート、境界づけられたコンテキストのマイクロサービスへのマッピング
2.4.5 イベントストーミング
2.5 マイクロサービス向けのドメイン駆動設計（DDD）の例
2.6 ビジネスドメイン境界の代替手段
2.6.1 変動性
2.6.2 データ
2.6.3 技術
2.6.4 組織
2.7 混合モデルと例外
2.8 まとめ
3章 モノリスの分割
3.1 目標を持つ
3.2 漸進的な移行
3.3 ほとんどの場合、モノリスは敵ではない
3.3.1 時期尚早な分解の危険性
3.4 まず何を分割すべきか
3.5 階層による分解
3.5.1 コードファースト
3.5.2 データファースト
3.6 便利な分解パターン
3.6.1 ストラングラーフィグパターン
3.6.2 並列実行
3.6.3 機能トグル
3.7 データ分解における懸念
3.7.1 パフォーマンス
3.7.2 データ完全性
3.7.3 トランザクション
3.7.4 ツール
3.7.5 レポートデータベース
3.8 まとめ
4章 マイクロサービスの通信スタイル
4.1 プロセス内からプロセス間へ
4.1.1 パフォーマンス
4.1.2 インタフェースの変更
4.1.3 エラー処理
4.2 プロセス間通信のための技術：多数の選択肢
4.3 マイクロサービスの通信スタイル
4.3.1 うまく組み合わせる
4.4 パターン：同期ブロッキング
4.4.1 利点
4.4.2 欠点
4.4.3 同期ブロッキングの用途
4.5 パターン：非同期非ブロッキング
4.5.1 利点
4.5.2 欠点
4.5.3 非同期非ブロッキングの用途
4.6 パターン：共通データを介した通信
4.6.1 実装
4.6.2 利点
4.6.3 欠点
4.6.4 共通データを介した通信の用途
4.7 パターン：リクエスト/レスポンス通信
4.7.1 実装：同期と非同期
4.7.2 リクエスト/レスポンス通信の用途
4.8 パターン：イベント駆動通信
4.8.1 実装
4.8.2 イベントの中身
4.8.3 イベント駆動通信の用途
4.9 注意深く進める
4.10 まとめ
第Ⅱ部 実装
5章 マイクロサービスの通信の実装
5.1 理想的な技術の探索
5.1.1 後方互換性を容易にする
5.1.2 インタフェースを明示的にする
5.1.3 APIを技術非依存にする
5.1.4 コンシューマにとって単純なサービスにする
5.1.5 内部実装の詳細を隠す
5.2 技術選択
5.2.1 リモートプロシージャコール（RPC）
5.2.2 REST
5.2.3 GraphQL
5.2.4 メッセージブローカー
5.3 シリアライゼーション形式
5.3.1 テキスト形式
5.3.2 バイナリ形式
5.4 スキーマ
5.4.1 契約の構造的破壊と意味的破壊
5.4.2 スキーマを使うべきか
5.5 マイクロサービス間の変更に対処する
5.6 破壊的変更の回避
5.6.1 拡張変更
5.6.2 耐性のあるリーダー
5.6.3 適切な技術
5.6.4 明示的なインタフェース
5.6.5 偶発的な破壊的変更の早期把握
5.7 破壊的変更の管理
5.7.1 ロックステップデプロイ
5.7.2 互換性のないマイクロサービスバージョンの共存
5.7.3 旧インタフェースのエミュレーション
5.7.4 どちらのアプローチが好ましいか
5.7.5 社会契約
5.7.6 利用の追跡
5.7.7 極端な手段
5.8 マイクロサービスの世界における、DRYとコード再利用の危険性
5.8.1 ライブラリを介したコード共有
5.9 サービス検出
5.9.1 ドメインネームシステム（DNS）
5.9.2 動的サービスレジストリ
5.9.3 人を忘れない
5.10 サービスメッシュとAPIゲートウェイ
5.10.1 APIゲートウェイ
5.10.2 サービスメッシュ
5.10.3 他のプロトコルはどうか
5.11 サービスの文書化
5.11.1 明示的なスキーマ
5.11.2 自己記述型システム
5.12 まとめ
6章 ワークフロー
6.1 データベーストランザクション
6.1.1 ACIDトランザクション
6.1.2 ACIDでも、原子性に欠けるのか
6.2 分散トランザクション：2フェーズコミット
6.3 分散トランザクションはお断り
6.4 サーガ
6.4.1 サーガの障害モード
6.4.2 サーガの実装
6.4.3 サーガと分散トランザクションの比較
6.5 まとめ
7章 ビルド
7.1 継続的インテグレーション（CI）とは
7.1.1 本当にCIを行っているか
7.1.2 ブランチモデル
7.2 ビルドパイプラインと継続的デリバリ（CD）
7.2.1 ツール
7.2.2 トレードオフと環境
7.2.3 成果物の作成
7.3 ソースコードとビルドのマイクロサービスへのマッピング
7.3.1 1つの巨大リポジトリ、1つの巨大ビルド
7.3.2 パターン：マイクロサービスごとに1つのリポジトリ（別名マルチリポ）
7.3.3 パターン：モノリポ
7.3.4 どの方法を使うべきか
7.4 まとめ
8章 デプロイ
8.1 論理から物理へ
8.1.1 複数インスタンス
8.1.2 データベース
8.1.3 環境
8.2 マイクロサービスのデプロイの原則
8.2.1 分離された実行
8.2.2 自動化の重視
8.2.3 IaC（コードとしてのインフラ）
8.2.4 停止時間のないデプロイ
8.2.5 望ましい状態の管理
8.3 デプロイの選択肢
8.3.1 物理マシン
8.3.2 仮想マシン（VM）
8.3.3 コンテナ
8.3.4 アプリケーションコンテナ
8.3.5 PaaS（Platform as a Service、サービスとしてのプラットフォーム）
8.3.6 FaaS（Function as a Service、サービスとしての関数）
8.4 どのデプロイオプションが自分に適しているか
8.5 Kubernetesとコンテナオーケストレーション
8.5.1 コンテナオーケストレーションの例
8.5.2 Kubernetesの概念の簡略図
8.5.3 マルチテナントとフェデレーション
8.5.4 CNCF（Cloud Native Computing Foundation）
8.5.5 プラットフォームと移植性
8.5.6 Helm、Operator、CRD
8.5.7 Knative
8.5.8 将来
8.5.9 Kubernetesを使うべきか
8.6 プログレッシブデリバリ
8.6.1 デプロイとリリースの分離
8.6.2 プログレッシブデリバリへの移行
8.6.3 機能トグル
8.6.4 カナリアリリース
8.6.5 並列実行
8.7 まとめ
9章 テスト
9.1 テストの種類
9.2 テストスコープ
9.2.1 単体テスト
9.2.2 サービステスト
9.2.3 エンドツーエンドテスト
9.2.4 トレードオフ
9.3 サービステストの実装
9.3.1 モックかスタブか
9.3.2 高度なスタブサービス
9.4 （扱いにくい）エンドツーエンドテストの実装
9.4.1 信頼できない脆弱なテスト
9.4.2 誰がエンドツーエンドテストを書くか
9.4.3 エンドツーエンドテストの実行期間
9.4.4 積み上がる大きな山
9.4.5 メタバージョン
9.4.6 独立テスト容易性の欠如
9.5 エンドツーエンドテストを避けるべきか
9.5.1 契約テストとコンシューマ駆動契約（CDC）
9.5.2 結論
9.6 開発者体験
9.7 本番前環境でのテストから本番環境でのテストへ
9.7.1 本番環境でのテストの種類
9.7.2 本番環境でのテストを安全にする
9.7.3 平均故障間隔（MTBF）よりも平均修復時間（MTTR）か
9.8 機能横断テスト
9.8.1 パフォーマンステスト
9.8.2 堅牢性テスト
9.9 まとめ
10章 監視から可観測性へ
10.1 断絶、パニック、混乱
10.2 単一マイクロサービス、単一サーバ
10.3 単一マイクロサービス、複数サーバ
10.4 複数マイクロサービス、複数サーバ
10.5 可観測性と監視の違い
10.5.1 可観測性の柱？あまり高速ではない
10.6 可観測性の構成要素
10.6.1 ログ集約
10.6.2 メトリック集約
10.6.3 分散トレーシング
10.6.4 うまくいっているか
10.6.5 アラート
10.6.6 セマンティック監視
10.6.7 本番環境でのテスト
10.7 標準化
10.8 ツールの選択
10.8.1 大衆性
10.8.2 統合しやすさ
10.8.3 コンテキストの提供
10.8.4 リアルタイム
10.8.5 自分たちの規模に合っている
10.9 マシン内の専門家
10.10 開始する
10.11 まとめ
11章 セキュリティ
11.1 基本原則
11.1.1 最小権限の原則
11.1.2 多層防御
11.1.3 自動化
11.1.4 デリバリプロセスへのセキュリティの組み込み
11.2 サイバーセキュリティの5つの機能
11.2.1 特定
11.2.2 保護
11.2.3 検知
11.2.4 対応
11.2.5 復旧
11.3 アプリケーションセキュリティの基礎
11.3.1 資格情報（クレデンシャル）
11.3.2 パッチ適用
11.3.3 バックアップ
11.3.4 再構築
11.4 暗黙の信頼とゼロトラスト
11.4.1 暗黙の信頼
11.4.2 ゼロトラスト
11.4.3 併用のバリエーション
11.5 データをセキュアにする
11.5.1 転送データ
11.5.2 保存データ
11.6 認証認可
11.6.1 サービス間認証
11.6.2 人の認証
11.6.3 一般的なシングルサインオン（SSO）の実装
11.6.4 シングルサインオン（SSO）ゲートウェイ
11.6.5 粒度の細かい認可
11.6.6 混乱した代理問題
11.6.7 一元的な上流での認可
11.6.8 認可の分散化
11.6.9 JSON Web Token（JWT）
11.7 まとめ
12章 レジリエンス
12.1 レジリエンスとは
12.1.1 堅牢性
12.1.2 回復性
12.1.3 グレースフルな拡張性
12.1.4 持続的な適応性
12.1.5 そして、マイクロサービスアーキテクチャ
12.2 障害はどこにでもある
12.3 どの程度が多すぎるのか
12.4 機能低下
12.5 安定性パターン
12.5.1 タイムアウト
12.5.2 再試行（リトライ）
12.5.3 バルクヘッド
12.5.4 サーキットブレーカー
12.5.5 分離性
12.5.6 冗長性
12.5.7 ミドルウェア
12.5.8 冪等性
12.6 危険性の分散
12.7 CAP定理
12.7.1 一貫性を犠牲にする
12.7.2 可用性を犠牲にする
12.7.3 分断耐性を犠牲にするか
12.7.4 APかCPか
12.7.5 オールオアナッシングではない
12.7.6 そして実世界
12.8 カオスエンジニアリング
12.8.1 ゲームデイ
12.8.2 本番環境実験
12.8.3 堅牢性の先へ
12.9 非難
12.10 まとめ
13章 スケーリング
13.1 スケーリングの4つの軸
13.1.1 垂直スケーリング
13.1.2 水平複製
13.1.3 データのパーティション分割
13.1.4 機能分解
13.2 モデルの組み合わせ
13.3 小さく始める
13.4 キャッシュ
13.4.1 パフォーマンスのためのキャッシュ
13.4.2 スケールのためのキャッシュ
13.4.3 堅牢性のためのキャッシュ
13.4.4 どこでキャッシュするか
13.4.5 無効化
13.4.6 キャッシュの黄金律
13.4.7 鮮度と最適化
13.4.8 キャッシュポイズニング：教訓
13.5 オートスケーリング
13.6 再出発
13.7 まとめ
第Ⅲ部 人
14章 UI
14.1 デジタルへ向けて
14.2 所有権モデル
14.2.1 専任フロントエンドチームに向かう要因
14.3 ストリームアラインドチームを目指して
14.3.1 専門家の共有
14.3.2 一貫性の保証
14.3.3 技術的課題の克服
14.4 パターン：モノリシックフロントエンド
14.4.1 モノリシックフロントエンドを使う場合
14.5 パターン：マイクロフロントエンド
14.5.1 実装
14.5.2 マイクロフロントエンドを使う場合
14.6 パターン：ページベースの分解
14.6.1 ページベースの分解の用途
14.7 パターン：ウィジェットベースの分解
14.7.1 実装
14.7.2 ウィジェットベースの分解を使う場合
14.8 制約
14.9 パターン：中央集約ゲートウェイ
14.9.1 所有権
14.9.2 各種のUI
14.9.3 複数の懸念
14.9.4 中央集約ゲートウェイを使う場合
14.10 パターン：BFF（フロントエンド向けのバックエンド）
14.10.1 BFFをいくつにするか
14.10.2 再利用とBFF
14.10.3 デスクトップWebなどのためのBFF
14.10.4 BFFを使う場合
14.11 GraphQL
14.12 ハイブリッドなアプローチ
14.13 まとめ
15章 組織構造
15.1 疎結合の組織
15.2 コンウェイの法則
15.2.1 証拠
15.3 チームサイズ
15.4 コンウェイの法則を理解する
15.5 小さなチーム、大きな組織
15.6 自律性
15.7 強い所有権と共同所有権の比較
15.7.1 強い所有権
15.7.2 共同所有権
15.7.3 チームレベルと組織レベルの比較
15.7.4 モデル間のバランスを取る
15.8 イネイブリングチーム
15.8.1 実践コミュニティ
15.8.2 プラットフォーム
15.9 共有マイクロサービス
15.9.1 分割が難しすぎる
15.9.2 横断的変更
15.9.3 デリバリのボトルネック
15.10 社内オープンソース
15.10.1 コアコミッターの役割
15.10.2 成熟度
15.10.3 ツール
15.11 プラグ可能なモジュラーマイクロサービス
15.11.1 変更のレビュー
15.12 孤立したサービス
15.13 ケーススタディ：realestate.com.au
15.14 地理的分散
15.15 逆コンウェイの法則
15.16 人
15.17 まとめ
16章 進化的アーキテクト
16.1 「名前が何だと言うの」
16.2 ソフトウェアアーキテクチャとは
16.3 変更を可能にする
16.4 進化するアーキテクト像
16.5 システム境界の定義
16.6 社会的構成概念
16.7 居住性
16.8 原則に基づいたアプローチ
16.8.1 戦略的目標
16.8.2 原則
16.8.3 プラクティス
16.8.4 原則とプラクティスの結合
16.8.5 実世界の例
16.9 進化的アーキテクチャへの指針
16.10 ストリームアラインド組織でのアーキテクチャ
16.11 チームの構築
16.12 必要な標準
16.12.1 監視
16.12.2 インタフェース
16.12.3 アーキテクチャ上の安全性
16.13 ガバナンスと舗装道路
16.13.1 見本
16.13.2 カスタマイズされたマイクロサービステンプレート
16.13.3 大規模での舗装道路
16.14 技術的負債
16.15 例外処理
16.16 まとめ
あとがき：すべてをまとめる
マイクロサービスとは
マイクロサービスへの移行
通信スタイル
ワークフロー
ビルド
デプロイ
テスト
監視と可観測性
セキュリティ
レジリエンス
スケーリング
UI
組織
アーキテクチャ
参考文献
今後について
最後に